Technical Field
Embodiments described herein generally relate to computer systems. In particular, embodiments described herein generally relate to the handling of interrupts and exceptions in computer systems.
Background Information
During operation, processors and computer systems commonly encounter what are known as interrupts and exceptions. The interrupts and exceptions generally represent conditions or events that exist in any of various locations in the system, within the processor, or within a currently executing program or task, and demand the attention of the processor. These interrupts and exceptions commonly cause the processor to suspend the processing of the currently executing program or task, and transfer control flow to an interrupt or exception handler module, which handles the interrupt or exception. This is often referred to as servicing or handling the interrupt or exception.
An interrupt often but not always refers to an external condition or event that occurs externally to a given processor or core. For example, an input and/or output (I/O) device, a timer, a peripheral device, an external processor, or other external hardware external to a given processor or core, may deliver the interrupt to the given processor or core. As another example, one core of a processor may deliver an interrupt to another core of the processor. However, not all interrupts are due to external events. Certain interrupts may be generated internally to a core and may be delivered as interrupts because they are asynchronous. Certain interrupts are not asynchronous. For example, there are certain synchronous core-originated interrupts. As another example, an interrupt may be asserted synchronously to reissue or reassert a missed or delayed (e.g., masked) interrupt. Typically, the majority of interrupts are asynchronous and are generated due to external conditions.
In contrast, an exception typically refers to an internal condition or event that occurs internally to a given processor or core. For example, exceptions commonly result from instructions being executed within the execution pipeline of a given processor or core. Exceptions generally represent synchronous events that are generally triggered by the execution of an instruction, and that are generally delivered with a specific relationship to the associated instruction. Certain types of synchronous events (e.g., faults) are generally delivered instead of executing the associated instruction, whereas other types of synchronous events (e.g., traps) are generally delivered immediately after executing the associated instruction.
Interrupts may be further classified as maskable interrupts and nonmaskable interrupts (NMI). Maskable interrupts may be masked. For example, certain processors have a maskability control, such as, for example, a flag, condition code, or status bit, that permits all maskable interrupts to be masked as a group. For example, certain Intel Architecture compatible processors have an interrupt flag (IF) that when cleared to binary zero does not permit the maskable interrupts to be delivered to software, but when set to binary one permits the maskable interrupts to be delivered to software.
In contrast to maskable interrupts, the nonmaskable interrupts (NMI) generally cannot be masked by the maskability control (e.g., the IF flag) used to mask the maskable interrupts. However, once an NMI has been delivered to software, certain processors may invoke a hardware condition to attempt to prevent the delivery of further NMI to software until handling of the initial NMI has completed. For example, it is described in part in Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 3A, Order Number 325462-051US, published June 2014, Sections 6.7 and 6.7.1, that upon receipt of a NMI, the processor may invoke certain hardware conditions to attempt to ensure that no other interrupts, including NMI interrupts, are received until an NMI handler responsible for handling the NMI has completed executing and returns control flow to the originating program or task. Such blocking or deferring of the delivery of further NMIs attempts to prevent nested execution of the NMI handler.